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Event-B is a refinement-based formal method that has been shown to be useful in developing concur- 
rent and distributed programs. Large models can be decomposed into sub-models that can be refined 
semi-independently and executed in parallel. In this paper, we show how to introduce explicit control 
flow for the concurrent sub-models in the form of event schedules. We explore how schedules can 
be designed so that their application results in a coiTectness-preserving refinement step. For practical 
application, two patterns for schedule introduction are provided, together with their associated proof 
obligations. We demonstrate our method by applying it on the dining philosophers problem. 

1 Introduction 

Event-B ITJ [181 is a state-based modelling framework with its roots in the guarded command language 
and the Action Systems formalism |l3l|4]|. It advocates proof -based correct-by-construction design, ab- 
straction, stepwise refinement and model decomposition as its main development strategies. 

In an Event-B model, events are chosen non-deterministically for execution following the interleav- 
ing principle and assuming atomicity of events. Much of the effort in the refinement approach, especially 
down in the refinement chain, is about the modeller aiming at diminishing the non-determinism in the 
model and introducing more deterministic ways of choosing events for execution. In an extreme case 
we can think of the modeller encoding this by using explicit program counters in the events. Work 
on introducing more deterministic schedules of events to Event-B has been studied extensively recently 
ll8l[TT][T4l|23. The goal has been to avoid explicitly coding this scheduling information into the events. 
We base our approach on fW], which concerns sequential systems, and extend it to concurrent programs. 

When models become large, decomposition strategies are used to focus on specific parts of the model. 
To be practical, such strategies need to support compositional verification in the sense that the modeller 
can locally reason about properties of a decomposed part of the model even though the underlying Event- 
B assumption is that events are chosen for execution from the entire set of events in the model. Relying on 
the atomicity requirement for events and the interleaving semantics for Event-B models the distinct parts 
can be interpreted as concurrently executing models [ 12 1. We show here how the scheduling approach of 
Bostrom [8] can be extended so that we can apply it in a compositional manner focusing only on part(s), 
or sub-model(s), of the model. We turn these sub-models into tasks, giving each of them a schedule of 
its own. The main addition to the original approach for sequential programs is to handle the possible 
interferences the concurrently executing tasks might exhibit. This can also be seen as an extension, with 
explicit schedules, of the Hoang-Abrial approach |[T2ll to development of concurrent programs. 

To facilitate practical use of our method, the schedules are introduced stepwise into a model via pat- 
terns. The patterns have associated proof obligations needed for ensuring the correctness of the refine- 
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ment step. As a result of the schedules, the scheduling information contained in events can be expressed 
explicitly in the schedules. 

In this paper, we focus on developing concurrent programs following the stepwise refinement ap- 
proach. Apart from the introduction of explicit schedules, concurrent programs are modelled within 
Event-B in a normal manner H] [121. While Event-B models can be executed as such using a non- 
deterministic scheduler ("animation"), our approach is designed to be close to traditional programming 
languages and results in models that are more efficient to execute on a computer, since more control flow 
information is explicitly stated in the schedule than using only Event-B [ 8] . The approach can also be 
used to replace parts of event behaviour with scheduling information as the scheduling concept as such 
is more general than what the focus is here. The schedules actually give a process-oriented specification 
style for Event-B modeller complementing its state-based style [9, 17|. 

The rest of this paper is structured as follows. In section |2l we present the foundations needed to 
understand our approach. We discuss set transformers (predicate transformers), the Event-B formalism 
and model decomposition. In section [3l we introduce a dining philosophers |13| Event-B model, which 
serves as a running example. Section |4] presents our main contributions. We introduce a scheduling 
language, show how schedules and tasks can be introduced, and demonstrate how it is possible to tackle 
the problem of interference from interleaving tasks. In section |5l we show how our framework can be 
applied on the dining philosophers example model. Finally, we sum the paper up in section |6l where we 
also discuss related work and future perspectives. 

2 Foundations 

2.1 Event-B 

Event-B fV. ^T0\ is a state-based modelling language. Models in Event-B consist of a dynamic and a 
static part, referred to as machines and contexts, respectively. The most important parts of a machine 
are variables, an invariant and events. Contexts contain parts such as constants, which can be referred 
to from machines. The state space is made up of the variables vi, v„ of types Zi, £„, and can be 
modelled as the cartesian product £ = Zi x ... x £„. The events E\, E,„ modify the state space, and 
can be written in the following general form ifTOll . where k & l..m: 

Ef, = when Gk{v,c) then v : \Ak{v,v' ,c) end. (1) 

Here, v represents the variables, c the constants seen by the machine, and the action v : |A/t(v,v',c) is 
the nondeterministic assignment assigning v any such values v' for which Ak{v,v' ,c) holds. Gk{v,c) 
represents the guard, which is a condition that must hold in order for the action to take place. An event 
is said to be enabled when its guard holds. Each machine also contains a special event Initialisation 
= V : |Ao(v',c) that initialises the state space. Unlike other events, it is unguarded and does not depend 
on a previous state. Events can be classified as ordinary, convergent or anticipated. This will be further 
explained in section [Z41 The invariant /(v,c) is a predicate constraining the values of the variables. 

2.2 Set transformers 

The events in Event-B can be viewed as set transformers ifTOl . Our presentation of events as set trans- 
formers is similar to the presentation in lilOl . 
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Consider a state space Z. A set transformer is a function ^(Z) — > that tranforms a set of states 

into another set of states. A weakest precondition set transformer 5 applied to a set q returns the largest 
set p from which S is guaranteed to reach a state in q. 

We have the following definitions to give a set transformer semantics to Event-B models: 



E = {v|T} 

i = {v\I{v,c)} 

gk = {v|G,(v,c)} (2) 

ak = {vt-^v'\Ak(v,v',c)} 

ao = {v'\Aoiv',c)} 



The set i describes the subset of the state space where the invariant / holds. Similarly, the sets gk (k G 
l..m) represent the state space subsets where guard Gk of the respective event is true. The relation 
describes the possible before-after states that can be achieved by the assignment of the respective event. 
Note that the initialisation results in a set ao instead of a relation, since it does not depend on the previous 
values of the variables. In this paper, we do not consider properties of constants c separately, as it is not 
important at this level of reasoning. The axioms that describe the properties of the constants are here 
considered to be part of the invariant. 

Let g and q be subsets of Z, and a be a relation. Furthermore, S, Si and S2 are arbitrary set transform- 
ers. The variables of E are denoted v. We have the following set transformers: 



M{q) = {v\a[{v}]Cq} 


(Nondeterministic update) 


(3) 


[g] il) = ^g^(l 


(Assumption) 


(4) 


{g}{q)=g^q 


(Assertion) 


(5) 


{SinS2){q)=Si{q)nS2{q) 


(Nondeterministic choice) 


(6) 


Si;S2{q) =Si{S2{q)) 


(Sequential composition) 


(7) 


S'^iq) = nX.{S;Xnsk\p){q) 


(Strong iteration) 


(8) 


S*{q) = vX.{S;Xnsk\p){q) 


(Weak iteration) 


(9) 


skip(<5r) = q 


(Stuttering) 


(10) 


magic(^) = true 


(Miracle) 


(11) 


abort(^) = false 


(Aborting) 


(12) 



Here, true and false are notations representing the sets £ and 0, respectively. This is because of conve- 
nience as well as the fact that the same notation is used in weakest precondition predicate transformers. 
We will also in general use predicate notation for describing subsets of the state space. (Nondeterminis- 
tic) update is used to assign values to variables in the state space, of which the stuttering set transformer 
skip is a special case, which leaves the state unmodified. The set transformer magic achieves the desired 
postcondition (even false) from any state, whereas abort does not guarantee to achieve any postcondi- 
tion q from any state. Not even termination is guaranteed. Assumption and assertion both behave as 
skip when g is true, but when false, assumption behaves as magic, whereas assertion behaves as abort. 
Nondeterministic choice represents demonic choice between set transformers, and sequential composi- 
tion combines set transformers in a sequential manner. An important property of demonic choice is that 
miraculous behaviour is avoided whenever possible, whereas aborting behaviour is always preferred. 
This is demonstrated by the following theorems, which follow directly from the definitions: 

magicn5 = 5 
abortn5 = abort 



p. Bostrom, F. Degerlund, K. Sere andM. Walden 



169 



The following properties can easily be derived, and the proofs can also be found in [51 : 

magic; 5 = magic abort; 5 = abort 

{gy,[h] = {g} [gyAh} = [g] (14) 

{gnh} = {gy,{h} [gnh] = [gy,[h] 

The iteration set transformers are used to achieve repeated execution. Iteration has been thoroughly 
discussed by Back and von Wright (Hill, and is only shortly summarised here. In both strong and weak 
iteration (5® and S*, respectively), the set transformer 5 is repeatedly executed a demonically chosen 
number of times. In strong iteration, the number of executions may be infinite, whereas for weak iteration 
it is guaranteed to be finite. Important theorems regarding iteration include the following unfolding rules: 

S"' =5;5'«nskip 

5* = 5; 5* n skip ^ ^ 

The set of states in which a set transformer 5 does not behave miraculously is called the guard of 5. 
The guard g(5') is given as: 

g{S) = -5(false) (16) 

We can now interpret an event E/^- from (1) as a set transformer. Using the definitions from (2), we 
can now give the set transformer [Ek] for Et as ifTOl : 

[Ek] = [gk];[ak] (17) 
For a set of events, {Ei , . . . ,Em}, we will use the denotion [E] for the expression [Ei] □ . . . □ [E,„]. 



2.3 Refinement 

Refinement is an important concept in Event-B. In this paper, we are mainly interested in refinement on 
the set transformer level, where it can be defined as [5] : 

5i □52 = Vs.5i(s) C52(5) (18) 

Here, 5i and 52 are set transformers. The intuitive interpretation of S\ C ^2 is that if S\ will reach a state 
in a set s, then so will ^2. We say that Si and ^2 are (refinement) equivalent if and only if Q Sj and 
S2 E . The relation between the set transformer view of refinement and a proof obligations approach 
has been studied in lITOl . 

A set transformed S is said to behave miraculously when executed in a state in the set ^(false), 
i.e. when the execution of 5 results in a post-state belonging to the empty set. We typically want to 
avoid introduction of more miraculous behaviour during refinement. Given a set transformer and a 
refinement ^2, ^2 does not exhibit more miraculous behaviour than if (false) = 5'2(false). 



2.4 Behavioural semantics 

We aim at using Event-B for construction of concurrent programs. Ultimately we like to show that 
a (concurrent) program S is correct given a precondition P and a postcondition Q. This correctness 
requirement is expressed in the Hoare triple: 



{P} S {Q} 



(19) 
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As the basis for our method, we use the development method for concurrent programs in (TT\. In this 
approach, the concurrent programs are built from atomic events in the same way as sequential programs 
are constructed [IJ. The program S is considered to consist of a collection of events. Note that there is no 
control flow other than non-deterministic choice of enabled events. Using the refinement based approach 
of Event-B, the program S that satisfies the pre/post-specification is derived stepwise. In order to use 
the refinement process to develop programs, the pre-/post-specification first has to be encoded into an 
initial Event-B model. This model has a specific structure LU : it has an initialisation event init, progress 
events prog and a finalisation event The events prog model (non-deterministically) the computation 
of the program, while fin models the post-condition 2 as a guard. The precondition is encoded in an 
external context machine. The semantics of an Event-B model M specifying a sequential program is in 
this setting: 

M= [init];\prog]*;\fin] (20) 

The system is first initialised, then prog is executed until the postcondition given by fin becomes true. 
The program can then terminate. The progress events prog are later refined to create a deterministic 
algorithm to reach the postcondition. We will also later need to show that the refinements E of prog 
terminate [1], i.e. [E]"^ = [E]*, as we are interested in total correctness. We assume that all Event-B 
models in the rest of the paper have this structure. Each event should maintain the invariant and therefore 
we assume that there is an invariant assertion {/} implicitly given before and after each event. 

We previously mentioned that events can be classified as ordinary, convergent or anticipated. This is 
relevant from a behavioural semantics point of view. Events are normally classified as ordinary, but it is 
sometimes necessary to prove that execution of events from a group will eventually terminate. All events 
belonging to this group should then be labelled as convergent. In practice, the termination property is 
proven by introducing a variant, and by showing that it is decreased by all convergent events. There 
is also the possibility of classifying events as anticipated. Labelling an event as anticipated indicates 
that it will be classified as convergent in a later refinement step, whereby the proof is postponed until 
further down the refinement chain. The notions anticipated or convergent should be for the events prog 
to guarantee that the model eventually terminates. 

2.5 Decomposition 

In order for a refinement based development method to be scalable there should be a way to decompose 
specifications into smaller parts that can be independently developed. The verification of refinement 
should thus be compositional, i.e., refinement of the individual parts should yield a refinement of the 
whole system. 

Here we will use a decomposition approach based on shared variables |T,'2'|. Following this approach, 
a model can be decomposed into sub-models that can themselves be further decomposed. The set of sub- 
models forms the complete system model. 

Definition 1. Sub-model. A sub-model is given as a 7-tuple {v,x,E ,X ,1 ,init,fin), where v and x are sets 
of variables, E and X are sets of events, I the invariant, init the initialisation and fin the finalisation. 

The variables v are only visible inside the sub-model, and will be referred to as internal variables. Vari- 
ables X are shared with other components and will be called external variables. The events E can refer 
to both V and x. Since they (also) manipulate the internal variables of the sub-model, they are denoted 
the internal events. The external events, X, are abstractions that only refer to the external variables x 
modelling the effects of events of other components. Hence, each event in X has a corresponding in- 
ternal event in another component. The initialisation of a sub-model is given by event init and the loop 
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termination guard is given by event fin. Note that a traditional Event-B model can be seen as a sub-model 
where the sets of external events and external variables are empty. A sub-model {v,x,E,X,I,init,fin) 
can be (further) decomposed into sub-models: 

{v,x,E,X,I,mit,fin) = {vi,xi,E\,Xi,h,initi,fini) \\ {v2,X2,E2,X2,l2,init2,fin2) 

The parallel composition of the sub-models is defined as: 

{vi,xi,Ei,Xi,Ii,initi,fini) \\ (v2,X2,E2,X2,l2,init2,fin2) ^21) 
= (vi U V2, (xi Ux2)\(vi U V2),£i UE2, {Xi UX2)\(£'i U£'2),/i /\l2,initi \\ init2, fm \\ fm) 

The parallel composition of two events is given as: 

when G then v : |5 end || when H then w : \R end 
= whenGA//thenv,w : |5A/?end ^ ' 

The semantics [M\ \ \ M2] of a the parallel composition M\ \\ M2 is given as: 

[Ml II M2] = inih II init2;{[E, \JE2U ((Xi UX2)\(£i U£2))])*; [-g(//«i || fm)] (23) 

The composition can be extended to arbitrary many components by recursively merging components 
pairwise. Since we want to do compositional proofs of refinement, we need to show that refinement of 
the individual sub-models lead to refinement of the entire system. First we need to prove that the external 
events provide abstractions of their internal counterparts {/i n 12}', [Xi] C [£2] □ [X2] and {/i n {2}', [X2] Q 
[El] r\[Xi]. To compositionally prove the refinement [Mi \\ M2] Q [M[ \\ M2], we then only need to prove 
the refinement [Mi] E [Mj], see 17]. 

We need to model that external events are executed a finite number of times, as they model the 
finite execution of their internal counterparts in other sub-models. Since these external events are not 
necessarily terminating by themselves, strong iteration cannot be used for describing behaviour of sub- 
models. The use of weak iteration can be seen as compositionally verifying partial correctness of a 
program, since termination is not ensured by set transformer refinement. However, we want to prove total 
correctness of the complete system. Since we in this approach [[I] [12l label the events E as anticipated 
or convergent, we show that the model will eventually terminate. Hence, total correctness follows from 
partial correctness in combination with the Event-B proof obligations that ensure termination 121 HI. 



3 Dining philosophers case study 
3.1 Problem description 

We are now ready to introduce a model of the dining philosophers ifTSll . which will serve as a running 
example. In this section, we show the initial model, we refine it, as well as decompose it into sub-models. 
The dining philosophers scenario can be described as follows. There are four philosophers sitting around 
a round table. Each philosopher has a plate in front of him, and there is a fork placed between each pair 
of adjacent plates. Each philosopher always does one of two things: think and eat, but not both at the 
same time. Furthermore, in order to eat, a philosopher must pick up both of the two forks located next to 
his plate. A philosopher can also drop a fork back into its original position, but only after he has eaten. 

The basic problem is that if the philosophers pick up the forks arbitrarily, there may be deadlocks. 
For example, if each philosopher picks up his right fork, there will not be any forks available anymore. 
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and no philosopher will have enough forks to eat. Since a philosopher will not drop a fork until he has 
eaten, there will be a deadlock. One well-known solution to this problem is to assign a number to each 
fork, and enforce that each philosopher picks up the adjacent fork with the lowest number first. In our 
case study we assume that we have four philosophers and number the forks as follows: Philosopher 1 
can access forks 1 and 2, philosopher 2 accesses forks 2 and 3, philosopher 3 uses forks 3 and 4, while 
philosopher 4 has access to forks 1 and 4. 



3.2 Modelling and refinement 

Initially we model the scenario as an abstract Event-B machine, where the four philosophers eat in a non- 
deterministic order. We only model one round, so each philosopher will only eat once. We introduce the 
variables phleaten thru ph4eaten, to model whether each philosopher has eaten. The event Intialisation 
sets these variables to FALSE. The events PhlEat thru Ph4Eat for the four philosophers then represent 
the progress of the model. They model that a philosopher eats which has not yet eaten by setting the cor- 
responding variable to TRUE. Finally, event Finalisation checks that all four philosophers have eaten. 
The Initialisation and Finalisation events are classified as ordinary events, whereas PhlEat, Ph4Eat 
are convergent, since they correspond to the prog variables in (l20l ). We now have: 



Initialisation {ordinary) = 

begin 

phleaten := FALSE 
phleaten := FALSE 
phSeaten := FALSE 
ph4eaten := FALSE 

end 



Finalisation (ordinary) = 

when 

phleaten = TRUE 
phleaten = TRUE 
phSeaten = TRUE 
ph4eaten = TRUE 

then 
skip 

end 



In the first refinement step we introduce the forks, which are modelled as variables /or^i ihmfork4. 
They are of type 0..4 to represent which philosopher that currently holds the fork. Value represents 
the fork lying on the table. All forks are initialised to this value. There are 16 new events in this 
refinement step: two for each of the four philosophers getting their adjacent forks (e.g. Ph3GetFork3 and 
Ph3GetFork4), and two events for each philosopher releasing the corresponding forks (e.g. Ph3RelFork4 
and Ph3RelFork3). Note that philosopher 4 uses forks 1 and 4. 

In order to be able to prove that the new events will not take over the execution, we classify them as 
convergent and give a variant that they decrease. There is no variable that can be used as a variant, but 
when each new event is executed it will disable itself and it will not be enabled again. Hence, we define 
a function v as follows: 



variables 

phleaten 
phleaten 
phSeaten 
ph4eaten 



invariant 

phleaten £ BOOL 
phleaten £ BOOL 
phSeaten £ BOOL 
ph4eaten G BOOL 



PhlEat {convergent) = 
when 

phleaten = FALSE 
then 

phleaten := TRUE 
end 
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V = { {FALSE, FALSE, FALSE) ^ 5, 
{TRUE, FALSE, FALSE) h-). 4, 
{TRUE, TRUE, FALSE) ^ 3, 
{TRUE, TRUE, TRUE) ^ 2, 
{TRUE, FALSE, TRUE) ^ I, 
{FALSE, FALSE, TRUE) iH- 0} 

The first and second dimension of the triple correspond to whether a philosopher is holding his left or 
right fork, respectively. The third one indicates whether he has already eaten or not. The variant is then 
formed as a sum of the values of function v applied on the variables of each philosopher. The refined 
model is now as follows: 



variables 

forkl 

fork! 

forks 

fork4 

phleaten 

ph2eaten 

phSeaten 

ph4eaten 



invariant 
forkl e 0..4 
forkl € 0..4 
fork3 e 0..4 
fork4 e 0..4 

variant 

v{bool{fork\ = \) ,bool{f orkl = \), phleaten) 
+v{bool{fork2 = 2),bool{fork3 = 2),ph2eaten) 
+v{bool{fork3 = 3),bool{fork4 = 3),ph3eaten) 
+v{bool {forkl = 4) , bool {fork4 = 4) , pMeaten) 



Initialisation {ordinary) 
begin 



forkl := 




forkl := 




fork3 := 




fork4 := 




phleaten : 


= FALSE 


phleaten : 


= FALSE 


phSeaten : 


= FALSE 


ph4eaten : 


= FALSE 



end 



PlilGetForkl (convergent) 
when 

forkl = 

phleaten = FALSE 
then 

forkl := 1 
end 



PhlGetFork2 (convergent) 
when 

forkl = 1 

forkl = 

phleaten = FALSE 
then 

forkl := 1 
end 



PhlEat (convergent) = 
when 

forkl = I 

forkl = 1 

phleaten = FALSE 
then 

phleaten := TRUE 
end 



PhlReIFork2 (convergent) = 
when 

forkl = 1 

phleaten = TRUE 
then 

forkl := 
end 



PhlRelForkl (convergent) = 
when 

forkl= 
forkl= I 

phleaten = TRUE 
then 

forkl := 
end 



Finalisation (ordinary) 

when 

forkl = 
forkl = 
forks = 
fork4 = 
phleaten = TRUE 
phleaten = TRUE 
phSeaten = TRUE 
ph4eaten = TRUE 

then 
skip 

end 



Note that when the v function is called, the fork variables are not directly passed as parameters. Instead, 
we check whether the currently evaluated philosopher holds the fork or not. The bool function is a 
technicality of Event-B that is needed to convert the result of the comparison into a value of BOOL. 



174 



Concurrent Scheduling ofEvent-B Models 



The events corresponding to philosophers 2, 3 and 4 eating, as well as picking up and releasing their 
respective forks are analogous to the events of philosopher 1, and are thus not shown here. We now 
have a refined model for the four philosophers eating, and in the next subsection we will decompose this 
model. 



3.3 Decomposition 

In the decomposition step we separate the functionality of the four philosophers in such a way that each 
philosopher constitutes a sub-model of its own. The partitioning we achieve is shown in the table below. 
Since philosophers 2 and 4 share fork 2 and fork 1, respectively, with philosopher 1, the external events 
of sub-model 1 are Ph2GetFork2, Ph2RelFork2, Ph4GetForkl and Ph4RelForkl. Analogous reasoning 
is used to find the external events of the other sub-models. 





Sub-model 1 


Sub-model 2 


Sub-model 3 


Sub-model 4 


Internal 
events 


PhlEat 
PhlGetForkl 
PhlRelForkl 
PhlGetFork2 
PhlRelFork2 


Ph2Eat 
Ph2GetFork2 
Ph2RelFork2 
Ph2GetFork3 
Ph2RelFork3 


Ph3Eat 
Ph3GetFork3 
Ph3RelFork3 
Ph3GetFork4 
Ph3RelFork4 


Ph4Eat 
Ph4GetForkl 
Ph4RelForkl 
Ph4GetFork4 
Ph4RelFork4 


External 
events 


Ph2GetFork2 
Ph2RelFork2 
Ph4GetForkl 
Ph4RelForkl 


PhlGetFork2 
PhlRelFork2 
Ph3GetFork3 
Ph3RelFork3 


Ph2GetFork3 
Ph2RelFork3 
Ph4GetFork4 
Ph4RelFork4 


PhlGetForkl 
PhlRelForkl 
Ph3GetFork4 
Ph3RelFork4 



4 Concurrent programs 

This far, we have considered model decomposition, resulting in sub-models that can be refined semi- 
independently. We are now ready to examine how these sub-models can be executed in a concurrent or 
parallel setting. This problem has been studied in [12J, which is a case study showing how to decompose 
Event-B models into concurrently executing sub-models. Here we extend this approach by giving sub- 
models explicit flow control in the form of event schedules, instead of the traditional nondeterministic 
choice. An important concept in our approach is the concept of tasks, which we define as follows: 

Definition 2. Task. A task is an 8-tuple {v,x,E,X,I,init,fin,S) where v are the internal variables, x the 
external variables, E the internal events, X the external events, I the invariant, init the initialisation, 
fin the loop termination condition, and S is a schedule conforming to the syntax in f l24D concerning the 
internal events E. 

Since all coordinates, except for S, are the same as in a sub-model, a task can be seen as an extension 
of the sub-model concept. Whereas the events of traditional decomposed sub-models are executed non- 
deterministically, the internal events of a task are scheduled according to S. The schedule S may only 
consist of internal events, and the set of events in the schedule is denoted 6(5). We assume that E = e(5), 
since if an internal event was not included in the schedule, it would never be executed. 
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4.1 Scheduling language 

In order to describe schedules of events we give a small scheduling language lH, which adheres to the 
following syntax: 

S ::= PS-^S\PS 

PS ::= do5od \ S,W ...WS„ \ E \ {g} ^^^^ 

Here — > represents sequential composition, [] non-deterministic choice, do od is a loop, E an event and 
{g} is an assertion. 

4.2 Semantics of tasks 

The semantics of schedules is given using a function sched that maps each schedule to the corresponding 
set transformer as in | 8 |. However, when scheduling the events in a task we need to consider interference 
from other tasks. A goal of the scheduling language is to be able to express schedules of internal events in 
such a way that interference from external events does not have to be explicitly taken into account. Such 
interference freedom is instead proven separately. We now recursively define a function sched(5,X) 
where S is a schedule, X is the set of external events. 

sched{PS-^S,X) = sched sched 

sched(do5od ,X) = ([g([e(5) UX])];sched(5,X))*; hg([e(S) UX])] 

sched(5i O ... = sched(Si,X) n . . . nsched(5„,X) (25) 

sched (£,X) = [X]*;[E];[X]* 

sched(U},X) = {g} 

The scheduling function takes the schedule S, as well as the set of external events X as input and outputs a 
set transformer containing both internal and external events. An arbitrary (but finite) number of external 
events X can occur before and after an internal event £" in a schedule. This is modelled by the set 
transformer [X]* on both sides of the event. 

Consider a system consisting of two tasks Ti = {vi,xi,Ei,Xi,initi,fini,Si) and T2 = {v2,X2,E2,X2, 
init2,fin2,S2)- To find the complete system behaviour, we need to compose the tasks, i.e. obtain Ti \\ T2. 
However, the number of interleavings of atomic set transformers grows exponentially with the length of 
the schedule IT91I . Hence, we need an appropriate approach to reason about the interleavings in order to 
make refinement proofs manageable. Here we make the restriction that we only consider tasks where the 
set transformers obtained after scheduling can be decomposed into a loop containing the demonic choice 
of atomic set transformers. This is an extension of the approach used in [12], where the programs are 
built from atomic events that are chosen non-deterministically for execution. Composition of such tasks 
can be easily handled fJ). We have the following requirement for schedulability in our approach: 

3Sii , . . .,Su ■ sched (5i ,Xi) = n . . . n5i„ n [Xi])*; [/mi] (26) 

where all Sn are atomic compositions of internal events. Using these atomic set transformers we can 
now use the traditional parallel composition Q- The semantics of the composition of the whole system 
T\ \\T2 is now given as: 

[Ti II T2] = [initi II init2];{{niSu) H (ny^jy))*; II fm] (27) 

This approach thus extends the decomposition method in 121 [121 with the possibility to reason about 
groups of sequentially scheduled events, instead of only individual ones. However, to find the groups 
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^ii , . . . ,Sin is in general non-trivial. Here we will give special cases encoded as patterns to make the 
verification of schedules manageable in practise. 



4.3 Introduction of schedules 

Schedules are introduced for the sub-models as a refinement step, in which we convert sub-models into 
tasks. The introduction of schedules has to constitute a refinement step in order to ensure that the prop- 
erties we have already proved for the models before introduction of schedules are preserved. Note that 
we do not support scheduling of anticipated events, so they have to be turned into convergent ones before 
the introduction of schedules. 

We now need to show for the two tasks Ti = {vi,xi,Ei,Xi,initi,fini,Si) and T2 = (y2,X2,E2,X2,initi, 
fini,S2): 

[Ml II M2] C [n II T2\ (28) 

where sub-model M,- corresponds to task 7]- as M,- = {vi,Xi,Ei,Xi,initi,fini). As in the traditional de- 
composition method, we can use external events to perform compositional proofs of refinement. Here 
we rely on the property (l26l) to decompose schedule sched(S,,X,) into a loop consisting of atomic set 
transformers. We need to show that for all tasks Ti Q: 

{hni2y,[Xij]QSkj (29) 
([e(5,-)] n [Xi])*; [fim] □ sched(5,-,X,-) (30) 

In (l29l ) we assume that for any external event Xjj € Xi, there is one corresponding atomic set transformer 
Skj in another task T^. To give a practical approach to the decomposition of schedules required by (l26l ). 
we give patterns that give generic instantiations of the quantified variables. In the patterns we rely on 
special cases of scheduling constructs where we know we can prove ( |29l ) and (l30l ). Patterns thus encode 
reusable schedule structures. One such case is when the introduction of sequential behaviour does not 
alter the behaviour of the sub-model. Another useful special case is when the introduction of sequential 
behaviour does not modify the externally visible behaviour of a sub-model. We use the same scheduling 
approach as in |8|, where patterns are applied on schedules stepwise and we prove that each pattern 
application leads to a refinement of the previous application. 

A pattern consists of a precondition, a schedule, a result and a number of assumption. The precon- 
dition predicate describes under which conditions the pattern is applicable. The schedule part describes 
what schedule the pattern is intended for, and the result part gives the set transformer that is produced 
when the pattern is applied. The assumptions are extra conditions that have be fulfilled in order to use 
the pattern. 



Pattern 1 The first pattern. Pi , introduces sequential behaviour into a sub-model. 



Pi{Ei,h,g,S,X) 
Precondition 
Schedule 
Result 

Assumption 1 
Assumption 2 
Assumption 3 
Assumption 4 
Assumption 5 



h 

E, ^{g}^S 

{h};X*;EuX*;{g};sdne6{S,X) 
h C -g(e(5)) 

{gy,{xne{s))mxne{s)y,{g} 

{hy,XrX;{h} 

Ei=Er,{g} 



(31) 
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The first assumption states tliat tlie precondition h implies that the events following E\ are disabled. The 
second assumption states that g ensures that E\ is disabled. Context information cannot be propagated in 
schedules without taking interference into account. Hence we need assumptions 3 and 4 to state that g 
and h are invariant with respect to the environment. Furthermore, g should also be invariant for all events 
in the schedule S. The last assumption states that E\ will establish g. We also directly use the event name 
E\ instead of the set transformer [^i], as well as E instead of [E]. 

In order to stepwise use patterns we need to show that each application of a pattern is correct, i.e. that 
(l30l ) holds. In order to do that, we assume that sched(S,X) represents a yet unscheduled loop of events 
sched(5',X) = (e(5') nX)*; [g{&{S) nX)]. We instantiate the existential quantifier in (|26l) with Sj as £■,-. 
Hence, we then need to show that {/z};sched(£'i {g} 5) = {h}\X*\EuX*\{g};sche6(S). Note that 
we also rely here on the properties (I32l)-(l34l) in Lemma [T] Note also that to ensure (l30l ) we here assume 
/ n -ig(£' nX) C g (//«). The reason for formulating the pattern in this way is to be able to use the same 
verification approach also to nested loops. 

Lemma 1. Context preservation. If {g}\S ^S',{g} then: 



The proofs of the properties in the lemma are straightforward and they are omitted for brevity. We can 
now prove the correctness of pattern P\ . 



{/z};sched(£i fe} hg(£i n£ nX)] 

= {Representation of sched(£'i — > {g} S)} 

{h};{EinEnX)*;[-^g[Ei UEUX)] 
= {Decomposition [6] : (5nr)* = {S;T*)*;T*} 

{h};X*; [El nE\X*)*\ hg(£'i UEUX)] 
= {Distributivity} 

{h]\X*; {{Ei\X*) n (£■; X*))*; [-^g{Ei UEUX)] 



{h}\X*\ {{Ei\X*)*\ ((£; X*)\ {Ei\X*)*)*\ [-^g{Ei HEHX)] 
= {Unfolding (HH)} 

{h]\X*; {{Ei\X*); {Ei;X*)*) n skip; ((£; X*); {Ei;X*)*)*; hg(£i HEHX)] 
= {Assumption 3 and Property ([33])}} 

{M;X*;{/z};(£i;X*);(£i;X*)*)n{/z};((£;X*);(£i;X*)*)*;hg(£in£nX)] 
= {Distributivity, assumption h C -^g{E) and disabledness of guard} 

{h};X*;{h};{EuX*y,{Ei;X*)*;{{E;X*y,{Ei;X*)*)*;[^g{EinEnX)] 
= {Assumption £1 = £1; {g}} 

{h};X*;{h};EuX*; {g}; {Ei;X*)*; ((£; X*); {Ei;X*)*)*; hg(£i HEHX)] 
— {Assumption g C -ig(£'i)} 

{h};X*; {h};Ei;X*; {g}; {E; X*; {Ei; X*)*)*; [^g{Ei HEHX)] 



{g};S = {g};S;{g} 

{gyx = {gyx;{8} 

{g}-s* = i{g};sr 



(32) 
(33) 
(34) 



Proof. 



= {Decomposition} 
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The proof of step * is: 



{Property (|34| and * below} 

{/z};X*; {/2};£i; {^};X*; {g}; ({g};£; X*; {^})*; hg(£i n£ nX)] 
{Leapfrog 6 : S;{T;S)* ^ {S;T)*;S} 

{h}-X*- {h};Ei; {g};X*; {{gj-E; X*)*; {g}; hg{Ei HEHX)] 
{Assumption g C -.g(£'i) and {g}; [g] = {g}} 
{h}-X*- {h}-E,; {g}-X*- {{g}; {E; X*))*; {g}; hg(£ HX)] 
{Lemma 9(c) in [6] : 5* = 5*; 5* and decomposition} 
{h};X*; {/i};£i; {g};X*; i{g};E H {ghX)*; hg(£ HX)] 
{Property (1331) and assumption 5} 
{h};X*;EuX*;{g};{{g};En{g};Xy;[^giEnX)] 
{Representation of sched(5,X)} 
{h}-X*;EuX*- {g};sched{S,X) 



{{g}-E-X*-{Ei-X*r)* 

{Assumption 3 and Properties ((32)) and (|33t l 

{{g};E;X*;{g};{EuX*rr 
{Assumption 2} 

{{g};E;X*;{g}r 



□ 



Pattern 2 The second pattern, P2, also introduces sequential behaviour. However, this time we show 
that we can group local behaviour E2 to an arbitrary event. 



P2{E,,E2,h,g,Si,X) 
Precondition 
Schedule 
Result 

Assumption 1 
Assumption 2 
Assumption 3 
Assumption 4 
Assumption 5 
Assumption 6 
Assumption 7 



h 

Ei^E2^{g}^S 
{h};X*;EuX*;E2;X*;{g};5ched{S,X) 
h C -g(e(5)) 

gc^g{EinE2) 

E2,X = X;E2 
{giE2)};X=X;{g{E2)} 
{g};{Xne{S))mxne{S)y,{g} 
{h};X QX;{h} 
E2 = E2, {g] 



(35) 



The assumptions in pattern P2 are similar to the ones in Pi . However, we additionally need assumptions 
that states that E2 and X do not interfere with each other (assumptions 3 and 4). To prove the correctness 
of the pattern we need to show that 

• By instantiation of ^ we get: {h};X*;EuX*;E2,X*;{g}\sc\\ed{S,X) = {/i}; (£i;£2 n e(S) n 

xy■[^g{E,v^E2V^e{s)v^x)] 

• Refinement (l30]l: {/i};sched(£'i ^£2 ^ {g} ^5,X) □ {/t}; (£'i;£2 n e(5) nX)*; [^g(£'i n^a n 

e{s)nx)] 

• Deadlock freedom: {/?}; (£1 ;£2 n e(S) nX)*; [^g(£i n e(5) nX)](false) = {/j};sched(£i 
E2 ^{g}^S, X){fa\se) 
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The deadlock freedom proof obligation ensures that the scheduling does not introduce new deadlocks. 
This was not needed in pattern Pi, as that pattern does not alter the behaviour of models. The proofs are 
straightforward using the assumptions in the pattern. This ensures that the scheduling does not introduce 
more deadlocks than in the original system. 

5 Scheduling of dining philosophers 

We now return to the running example introduced in section [3] Up till now, the dining philosophers 
model has been refined and split into sub-models. Now, we show how the sub-models can be turned 
into tasks by introducing schedules. In the scheduling process we use the patterns given in section [431 
Correctness will be proven by checking the assumptions of the patterns. We will concentrate on how to 
derive a schedule for task 1. The schedules for task 2, 3 and 4 can be derived analogously. 

Our approach is that the schedule should be formulated such that it fulfills the previously mentioned 
solution to the dining philosophers problem, i.e., that each philosopher should pick up the lower num- 
bered fork first. Since we first want to pick up fork number 1, we wish to schedule PhlGetForkl as 
the first event. The correct order of events will be PhlGetForkl, PhlGetForkl, PhlEat, PhlRelForkl, 
PhlRelForkl. This is captured by the following schedule: 

PhlGetForkl ^ {^i} ^ PhlGetFork2 PhlEat {^2} 
PhlRelFork2 {g^} PhlRelForkl {^4} 

The assertions in the schedule are needed to capture intermediate results and thereby enable verification 
of the schedule in smaller parts. 

We now want to prove that it is correct to schedule PhlGetForkl as the first event. To show this, 
we will follow pattern Pi introduced in Section 1431 and show that the assumptions 1 - 5 for the pattern 
are fulfilled. We instantiate pattern Pi as Pi{PhlGetForkl,hi,gi,S,-,Xti), where hi = {forkl 7^ 1 A 
phleaten = FALSE), gi = {forkl = 1 V phleaten = TRUE), Sr = PhlGetFork2 PhlEat {§2} ^ 
PhlRelFork2 ^ {§3} ^ PhlRelForkl ^ {§4} and Xa = {Ph2GetFork2, Ph4GetForkl, Ph2RelFork2, 
Ph4RelForkl}. 

We chose precondition hi so that it also is an invariant for the external events Xn. Here, hi states 
that philosopher 1 does not hold his forks nor has he eaten. Moreover, we chose assertion gi to state that 
philosopher 1 has picked up fork 1 or eaten. This condition is an invariant for the events e(5,-) UX,i and 
established by PhlGetForkl. We now confirm that the assumptions for the pattern hold: 

• h\ = {forkl ^ 1 A phleaten = FALSE) implies that events in e{Sr) are disabled. This holds, since 
they are only enabled when philosopher 1 holds fork 1 or has eaten. 

• The assertion gi = {forkl = 1 V phleaten = TRUE) following event PhlGetForkl ensures that 
PhlGetForkl is disabled. Since is a negation of the guard of PhlGetForkl the second assump- 
tion is fulfilled. 

• g\ is an invariant of the environment &{Sr) UXfi. This is fulfilled, since in the events of e(5r) 
philosopher 1 holds fork 1 or has eaten. Moreover, the events in Xt\ that share fork 1 are not 
enabled when philosopher 1 holds fork 1, and none of these events modify variable phleaten. 

• /zi is an invariant of the external events Xti. Since none of the external events model that philoso- 
pher 1 picks up fork 1 or modify variable phleaten, this assumption holds. 

• Event PhlGetForkl establishes gi . This holds trivially since PhlGetForkl models that philosopher 
1 picks up fork 1 {forkl := 1). 
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To verify the complete schedule, we then apply pattern P2 once, followed by three applications of Pi . 
In the last application of P\ , the schedule following the assertion is empty. This can be interpreted as a 
schedule with an event that is always disabled. When task 1 has been fully proven, the whole procedure 
is repeated to schedule tasks 2, 3 and 4 in the order shown in the table below (for simphcity, the assertions 
are not shown). 



Task 1 


Task 2 


Task 3 


Task 4 


PhlGetForkl 


Ph2GetFork2 


Ph3GetFork3 


Ph4GetForkl 


PhlGetFork2 


Ph2GetFork3 


Ph3GetFork4 


Ph4GetFork4 


PhlEat 


Ph2Eat 


Ph3Eat 


Ph4Eat 


PhlRelFork2 


Ph2RelFork3 


Ph3RelFork4 


Ph4RelFork4 


PhlRelForkl 


Ph2RelFork2 


Ph3RelFork3 


Ph4RelForkl 



6 Conclusions and related work 

In this paper, we have proposed a method of correct-by construction development of concurrent pro- 
grams using Event-B. The programs are first developed as proposed by Hoang and Abrial |[T2| . From 
this development process we obtain a number of sub-models that communicate via shared variables, 
which represent the program. We then introduce explicit control flow in the form of schedules for each 
sub-model, so that each sub-model/schedule corresponds to exactly one task. The schedules are intro- 
duced as correctness preserving refinements. We use a set-transformer semantics for Event-B, as well 
as well known algebraic rules f6l for the analysis of correctness. The schedules are verified in a step- 
wise manner, and each step carries some related proof obligations. The schedules enable more efficient 
implementation of the Event-B models as more explicit control flow information is available than for 
pure event-B models. We can, e.g., use the transformations in [81 to introduce traditional control flow 
constructs, such as while loops and if-statements, as well as remove unnecessary guards. Furthermore, 
the schedules give a process-oriented specification of the behaviour of the models. 

Our goal is to compositionally reason about concurrent programs. This has been a very active field 
of research |[T9l . Our approach directly extends the approach in |[T2l for development of concurrent 
programs with explicit schedules of events. Compositional reasoning in this setting goes back to the 
work of Owicki and Gries 1 16] and Jones' Rely-Guarantee reasoning [ 15 |. The decomposition method 
based on shared variables in Event-B [2, 12] is based on these ideas. Essentially the same approach is 
also available for action systems using the refinement calculus d. The theory for decomposition in the 
set-transformer setting is largely based on that paper. Several approaches to introducing control flow 
into Event-B models have been developed. Hallerstede's approach in [11] to adding control flow only 
deals with sequential programs and it is thus more related to Bostrom's earlier work |8]. The scheduling 
approaches in |[T4ll20l can also handle concurrent schedules. In |[T4ll the scheduling (referred to as flows) 
is expressed using a special purpose language, while in the approach f20| the scheduling is expressed 
in CSP The latter approach can be seen as an extension of the former. Processes or flows are both 
considered to communicate via shared events. Our focus is on compositional verification and scheduling 
of concurrent programs that use shared variables for communication. However, in both approaches not 
all events need to be scheduled, but non-scheduled events are considered interleaved in the scheduled. 
This could be used to take into account external events, and thus be used for compositional verification 
of shared variable programs also. Our contribution is threefold: 1) Compared to purely event-based 
modelling, we consider explicit schedules of events that can be interleaved 2) We do all analysis on the 
level of set transformers, which gives convenient formalism to algebraically perform the needed analysis 
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of Event-B models 3) We provide patterns and a method to develop patterns for introducing control flow 
in a stepwise manner. This is important, since verifying that a certain event schedule is correct can be 
very challenging and reusable scheduling structures can significantly aid in this task. 

Set- transformers give a powerful framework to reason about Event-B models on a high level of 
abstraction. They give a good basis for creating reusable patterns for scheduling, which are essential 
for practical applications. If schedules are introduced as a last refinement step, as in the example of 
this paper, existing tool support can be used for development up till, but not including, the scheduling 
step. Future work involves investigating tool support for schedule application. Generation of refinement 
proof obligations for scheduled models is also of interest, since that would allow for schedule intoduction 
earlier in the refinement chain. 
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